Solid-state drives (SSDs) support a set of commands that are used for administrative purposes. Some of these administrative commands are disruptive in nature and can result in an irrecoverable loss of data. Examples of these disruptive commands are a format command, a namespace deletion command, a firmware update command, etc. The format command releases logical block addresses (LBAs) on an SSD and clears the contents of the LBAs. The namespace deletion command releases the LBAs pertaining to a namespace specified in the command. The firmware update command updates the operational firmware on the SSD.
These disruptive administrative commands can be executed only by users with root privileges. Typically, the root privileges are the only security layer available for validating administrative commands. FIG. 1 shows a prior art authentication scheme 100 for executing an administrative command. An administrative command 111 can be issued to an SSD 130 using a command line interface (CLI) of a command line utility program or an application from a host operating system (OS) 110. The command line utility or the application may run in a user space of the host operating system. The administrative command 111 is sent to a device driver 120 that manages the control and operations of the SSD device 130. The device driver 120 may be running in a kernel space or a user space of the host operating system. The device driver 120 passes the administrative command 111 to the firmware of the SSD 130. The SSD firmware carries out the actual operation on the SSD 130 as instructed by the administrative command 111. Upon completion of the administrative command 111, the SSD firmware sends back a response 121 (e.g., success or failure) to the device driver 120. The device driver 120 then send the response 121 back to the host OS 110 from which the administrative command 111 is issued.
Traditionally, only a root-privileged user can initiate critical operation commands. If the root privileges are compromised, such critical operation commands can lead to irrecoverable data loss. The prior art authentication scheme 100 of FIG. 1 assumes that the command is already authenticated and has the necessary permissions. These administrative commands are usually configured as “privileged” operations. The runtime environment of the host OS 110 checks for the appropriate privileges (e.g., super-user) to execute the commands. The prior art authentication scheme 100 is vulnerable due to a lack of a preventive mechanism to stop a disruptive command issued with a malicious intent if the user credentials are compromised. The SSD 130 does not have any mechanism to ensure that the command issued is an intended one. A compromised administrative command issued to an SSD can lead to a permanent and irreversible data loss on the SSD.
Even a legitimate user can accidentally execute an administrative command by mistake. In this case, the SSD has no level of confirmation to ensure that a disruptive operation is indeed an intended one. For example, legitimate but unintended administrative commands can be accidentally issued in larger setups where a number of SSDs are deployed on multiple servers in a cluster.